home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Oct 89 / Z0064-Re Changing MacApp -Oct89 < prev    next >
Encoding:
Text File  |  1989-10-13  |  1.8 KB  |  44 lines  |  [TEXT/GEOL]
  1. Item    2762371                         12-Oct-89        16:19
  2.  
  3. From:   D4071                           Aapps, Russ Wetmore,PRT
  4.  
  5. To:     D2086                           Efficient Field Svc, C Faith,PRT
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    Re: Changing MacApp Source
  10.  
  11. Curtis -
  12.  
  13. It's not _always_ necessary to alter the given objects to do what you're
  14. suggesting.
  15.  
  16. In ViewEdit, for example, all view objects needed to be selectable,
  17. resizable, relocatable, reorderable, etc.  One option was add methods to
  18. TView in the MacApp source code, which would have made it difficult to
  19. upgrade to a new version of MacApp.  Another was to override every
  20. available view object and add redundant methods to each.  Neither option
  21. seemed desirable.
  22.  
  23. What I eventually did (thanks to a suggestion from David Goldsmith) was
  24. create a view "holder" object, implement the necessary common
  25. functionality there, and imbed each view object in a holder.  The view
  26. holder handles these common tasks, with events and choices being passed on
  27. to the view holder from its subordinate view when necessary. Sort of a
  28. poor man's multiple inheritance.
  29.  
  30. This trick obviously depends on the way the view hierarchy works.  As a
  31. more general solution, I suggested once that abstract objects should be
  32. inserted into the object hierarchy ahead of the lower base classes,
  33. subject to compile-time variables.  Thus, TView could be derived from a
  34. TAbstractView (derived in turn from TEvtHandler), with the source to
  35. TAbstractView coming from an included file which would remain external to
  36. the MacApp sources.  (This would be similar to the way additional view
  37. type definitions can be added to ViewTypes.r at compile time.)  I was
  38. outvoted at the time, but I still think it's a good idea.
  39.  
  40. 'Course, if Object Pascal handled multiple inheritance, this discussion
  41. would be moot...  :-)
  42.    [ Russ ]
  43.  
  44.